Sorry for the long delay. I left a few comments, but they don't need to be fixed. I have doubts about whether we should make inst_to_dict() and dict_to_inst() recursive. Perhaps we should deprecate these functions instead. Let me explain why.

1. You implemented recursive representation only for object properties, but nested objects can also be array elements and dictionary keys/values.
2. Arrays and dictionaries can be typed, so they also need to be represented in a special way (say, as {"@type": "Array", "@elem_builtin_type": "int", "@elements": [1, 2, 3]}). Because we can't, for example, put a dictionary representation of an object into an Array[Object].
3. Arrays, dictionaries, and objects are passed by reference. Currently, inst_to_dict() creates a shallow copy, and all reference types in the dictionary representation are the same values ​​as in the original object (see example below). If we make a deep version of inst_to_dict(), it would probably have to create duplicates, because of p. 2. This would be inconsistent with the flat version, which is essentially a separate serialization function with different behavior, hidden in inst_to_dict() behind an optional parameter.
4. We already have other serialization functions: var_to_bytes(), var_to_str(), and the new JSON functionality (see Ability to convert native engine types to JSON and back. #92656). I think 4 types of serialization is too many. var_to_str() has security concerns, but it seems like the new JSON methods are aimed at being more secure (at least they have appropriate parameters). I think we should focus on the core serialization methods and deprecate the GDScript specific inst_to_dict() and dict_to_inst() functions.

class Test:
    var a = []

func _ready():
    var test = Test.new()
    var dict = inst_to_dict(test)
    print(dict) # { "@subpath": ^"Test", "@path": "res://node.gd", &"a": [] }
    print(test.a) # []
    dict.a.append(1)
    print(dict) # { "@subpath": ^"Test", "@path": "res://node.gd", &"a": [1] }
    print(test.a) # [1]